Developer CD Series 1994…tember: Reference Library/Dev.CD Sep 94.toast/Technical Documentation/Misc. Standards/Multimedia Standards/Multimedia Standards Report -

Text File | 1992-11-12 | 7.8 KB | 160 lines | [TEXT/GEOL]

Multimedia Standards Report - MM Objects & Scriptware

Copyright 1992, Apple Computer, Inc.

"Multimedia Standards Report" - ISO & CCITT Joint Meeting on Multimedia Objects
and Scriptware, April 21-24, 1992.

Last week I attended 3 days of a 4 day joint international meeting of ISO and
CCITT members interested in developing a scripting standard for objects defined
by the MHEG (multimedia/hypermedia experts group) standard. Objects and state
conditions generated by object interactions are represented in ASN.1, ISO's
"language" for data representation. This is a Pascal like language optimized
for communication protocols and their service applications such as file
transfer and message handling. ASN.1 has fairly wide acceptance in Europe and
Japan, but very little in the U.S, due to the embedded base of successful
software as well as the Internet's de facto success.

Key MHEG concerns at this meeting centered around "composition of objects" and
how objects and object components may be manipulated by the scriptware engine.

The following were discussed in great detail:

1. what object handling is in MHEG/AVIs scope?
2. as only final form is specified in the scope of the standard (something
taken very seriously by ISO and CCITT), how does the group keep the scripting
work focused only on creating objects for final form interchange without
stating explicitly how final form presentation is done?
3. should the work be kept consistent with ODA's hypermedia user requirements?
4. the "glue" metaphor was used to discuss how AVIs can be used on objects to
be combined in space and time. Much discussion focused on when to use glue and
when it is outside the scope of MHEG to use glue.
5. how do we/or should we keep glue, objects and pointers separate?
6. a comparison with distributed databases was made, but nothing technically
concrete was decided.
7. the ability to update objects was discussed as being possible, but not
required.
8. it was decided that if one has to modify MHEG objects, the only way they
could do this (and stay within the scope of their charter) was to use other
MHEG objects (on the MHEG object to be modified). This will maintain final form
because one would be using a predefined and interchanged MHEG object to modify
another MHEG object. The way this would be supported between MHEG engines
(i.e., the interchange engines) is by using interchange numbers to indicate the
object being used to modify another MHEG object. This is described in a little
more detail below.

AVIs Overview:

The characteristics of an AVI environment were dicussed:

    •   an intelligent terminal is assumed.
    •   dedicated AVIs software is necessary.
    •   whether or not videotext should be supported is still open
        - some felt the short term solution could address videotext, but the
        long range solution should not.
    •   profiles may be defined for specific environments.
    •   conditional links may be provided. This is still an open issue.
    •   a synchronization agent should be defined.

Currently MHEG defines a composite object upon which 6 different possible
synchronization schemes may be applied. How this will affect AVIs has not yet
been determined.

Especially note items #2 and #4 below which describe what AVIs supposedly
provides.  My recommendation to Apple projects involved in scripting is to note
that the "characteristics" identified in item #5 below are considered "The 10
Commandments" by the organizations involved in scriptware standardization.

It was my opinion in the meeting that interchanging a "package" of media data
objects, scripts and references or links to external objects and functions may
provide a more robust model for portable applications and content rather than
forcing a complete cross-platform multimedia model on a scripting environment.
I also felt that some of the concepts defined by AVIs, such as "application
package" apply more to the media interchange standards problem than scripting.
This is more in line with what the U.S. based Interactive Multimedia
Association is working toward.

Attached is an excerpt from a trip report by Roger Price of IBM France who
attended the meeting. Roger was able to stay until Friday. I left Thursday
evening for an ISO SC 18 Hypermedia meeting that met Thursday through Tuesday
of the following week. Hence, Roger's notes describe more accurately the
conclusions of the meeting.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Attached Note <<<<<<<<<<<<<<<<<<<<<<<<
 From:    Roger Price       [phone]
 Subject: Trip Report - CCITT AudioVisual Interactive Service

 CCITT SG VIII/9 met in Geneva April 21-24 together with 7 ISO JTC1 SC29
 MHEG experts from the UK, France, Japan, Korea plus a US SC18 liaison (Rita
 Brennan from Apple).

 The meeting was almost entirely devoted to a technical study of the
 CCITT's requirements for audiovisual interactive (AVIs) scriptware for the
 future AVI service.

 The ISO SC29 MHEG people finally agreed with the CCITT SG VIII/9 people
 on the following view of the relationship between AVI applications and
 scripts and MHEG objects. (Personally I believe that this represents a
 significant achievement.) This view now has to be positioned in the
 larger generic functional definition to be provided by SC18/WG8.

 1) CCITT AVI Application package
    An AVI application package contains an AVI script, the objects and
    processes it refers to, and the declaration of parameters necessary
    for interpretation:

    .--------CCITT AVI application package----------.  Note that the
    |                .--------------. .-----------. |  external processes
    |                | AVI Script   | | External  | |  may be specified in
    | .------------. |              | | Processes | |  C++, Rexx AVA...
    | | General    | '--------------' '-----------' |
    | | Parameters | .--------------. .-----------. |
    | '------------' | MHEG Objects | | External  | |
    |                |              | | Objects   | |
    |                '--------------' '-----------' |
    '-----------------------------------------------'

 2) AVI Script
    An AVI script provides the sequencing and inter-relationships of
    MHEG objects by referring to their IDs and their attributes, possibly
    through messages.   It also provides tools to call external processes
    out of the scope of this recommendation.

 3) Required characteristics of the AVI Script
    * The script is intended to be revisable, it can be updated in pieces.
    * The script may be composed of self-standing modules.

 4) An AVI Script provides
    * Reference to MHEG object attributes.
    * Links between MHEG objects.
    * Global control of events other than input and time events.
    * Request for traces.
    * Check points (for navigation and warm-state recovery).
    * Updates (extension of MHEG mechanisms).
    * Invocation of external processes and data.
    * Recursivity of scripts.

 5) Required characteristics of the AVI Scripting language
    * It shall be interpretable.
    * It may be compilable.
    * It shall be recursive.
    * It shall be human readable, however it is not aimed at conveying
      the audiovisual author's intentions.   It is expected that the
      author will use an authoring system and not a text editor, since
      the scripting language is execution oriented.

 6) The protocols to be used are still to be chosen.  Candidates are DTAM
    and Stutel, but both will have to be modified.  (I believe that this
    may have a considerable impact on the evolution of IBM's mm products,
    and merits close attention.)   MHEG objects will have to carry
    additional parameters needed to support the future mm networks.
    (Again this notion of 'class of service' requirements associated with
    data structures is something which will impact many of our telecom
    products.)

Worldwide Multimedia!
Standards & Assns.
Standards
18-May-92